Conversation
- Add StoreId property to EmailAccount domain entity - Add GetEmailAccountsByStore(storeId) method to IEmailAccountService and EmailAccountService - Add EMAILACCOUNT_BY_STORE_KEY cache key - Update MessageProviderService to use store-specific email account as fallback - Update EmailAccountModel with StoreId and AvailableStores - Update EmailAccountProfile mapper to include StoreId - Update EmailAccountViewModelService to be async and populate available stores - Add EmailAccountController to Grand.Web.Store with CRUD + store isolation - Add EmailAccount views (List, Create, Edit, Partials/CreateOrUpdate) in Store area - Add Messages namespace to Store _ViewImports.cshtml - Update Admin EmailAccountController for async PrepareEmailAccountModel Agent-Logs-Url: https://github.com/grandnode/grandnode2/sessions/094d04cc-7d75-4a00-af14-f5bb77f05736 Co-authored-by: KrzysztofPajak <16772986+KrzysztofPajak@users.noreply.github.com>
Agent-Logs-Url: https://github.com/grandnode/grandnode2/sessions/094d04cc-7d75-4a00-af14-f5bb77f05736 Co-authored-by: KrzysztofPajak <16772986+KrzysztofPajak@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>
| if (string.IsNullOrEmpty(storeId)) | ||
| return await GetAllEmailAccounts(); | ||
|
|
||
| var key = string.Format(CacheKey.EMAILACCOUNT_BY_STORE_KEY, storeId); |
There was a problem hiding this comment.
@copilot when we update email account the data is dirty
There was a problem hiding this comment.
Fixed in d7be617. The separate EMAILACCOUNT_BY_STORE_KEY cache was the root cause — it held its own object instances that could become stale/mutated independently when an account's StoreId changed during an update. GetEmailAccountsByStore now filters in-memory from the already correctly-invalidated GetAllEmailAccounts cache, so there's only a single source of truth. The unused EMAILACCOUNT_BY_STORE_KEY constant has also been removed.
|
|
||
| protected virtual async Task<EmailAccount> GetEmailAccountOfMessageTemplate(MessageTemplate messageTemplate, | ||
| string languageId) | ||
| string languageId, string storeId = "") |
There was a problem hiding this comment.
MessageTemplate does not have a single StoreId — it uses LimitedToStores (bool) + Stores (list of store IDs), which is the standard GrandNode store-scoping pattern for multi-store visibility.
The storeId in GetEmailAccountOfMessageTemplate comes from the call site (e.g. the order-placed notification passes the order's StoreId). It's already threaded correctly through GetMessageTemplate(messageTemplateName, storeId) for the template lookup, and is now reused for the store-specific email account fallback.
…vent dirty data Instead of caching per-store results separately (which could hold stale/mutated objects when an account's StoreId changes), filter directly from the already correctly-invalidated GetAllEmailAccounts cache. Also removes the now-unused EMAILACCOUNT_BY_STORE_KEY constant. Agent-Logs-Url: https://github.com/grandnode/grandnode2/sessions/5697bb0d-b979-44be-8f1a-2f8c98ad8b5e Co-authored-by: KrzysztofPajak <16772986+KrzysztofPajak@users.noreply.github.com>
|
@copilot Grand.Web.Store should not see all available store |
…lableStores/PrepareEmailAccountModel calls Agent-Logs-Url: https://github.com/grandnode/grandnode2/sessions/d1fe358f-d64b-47c9-af25-cea72fae9de0 Co-authored-by: KrzysztofPajak <16772986+KrzysztofPajak@users.noreply.github.com>
Fixed in 84fdff0. The Store controller was calling Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
StoreIdproperty toEmailAccountdomain entityGetEmailAccountsByStore(storeId)toIEmailAccountServiceand implementationMessageProviderService.GetEmailAccountOfMessageTemplateto prefer store-specific account as fallbackStoreIdtoEmailAccountModelin AdminSharedEmailAccountProfilemapper to includeStoreIdEmailAccountViewModelServiceto be async and populate available storesEmailAccountControllerfor asyncPrepareEmailAccountModelEmailAccountControllertoGrand.Web.Storewith CRUD actions (store-isolated)Grand.Web.Store/Areas/Store/Views/EmailAccount/DefaultLanguage.xmlGetEmailAccountsByStorefilters fromGetAllEmailAccountscachePrepareAvailableStores/PrepareEmailAccountModelcalls from Store controller — Store area never shows the store selector and must not load all stores